1. Field of the Invention
The present invention relates to client-server application network communications. More specifically, the invention relates to managing client-server communications such that a client has access to all messages from a server.
2. Relevant Technology
Programmed computers are increasing modem day society's ability to do more work in less time and at less expense. The programs which execute on these computers cover a vast range of subjects and industries. These programs vary in their amount of utilization of computer hardware resources. In the end, it is the output of the computer such as, a report, a display, a printed document, and the like which provides the utility found in programmed computers.
Programs for computers may be a single program executing on one computer or a plurality of program modules distributed across a plurality of individual computers. Division of a single program into modules may be done for several reasons such as to protect ownership of a particular module, to save computer resources, or to broadly increase user access to specific program modules.
Division of a single program into program modules requires there be some form of communication rules or relationships between the program modules and hardware to transmit the communications. The relationships available are varied and often model the relationships amongst human beings. Examples of models include peer to peer, master/slave, and client/server. In each model, one program module takes on one role and a second program takes on the other role.
The hardware needed to transmit inter-program module communications is standard computer networking hardware which utilizes standard network protocols, e.g., ISO/OSI, IPX, SNA, OTMA, APPC, TCP/IP, to pass messages from one program module to the other. In addition, each computer on the network needs a network card capable of communicating across the network medium. The network medium may be Ethernet, token-ring, twisted pair, infrared, radio waves, other wireless mediums and the like. The network may be a local area network LAN, wide area network WAN, or global network such as the Internet.
Inter-program module messages contain two kinds of data, control data and message data. Depending on the network protocol, there may be one or more layers of control data. The control data instructs the network hardware how and where to transmit the message. The message data is the information the sending computer intended to transmit. Some protocols, such as Open Transaction Manager Access (“OTMA”), provide a portion of the control data which either program module may use to identify messages.
Of the models for inter-program module relationships, the client/server model is most prevalent. Client-Server programs are common in most every aspect of government, business, and commerce today. The development of the Internet has magnified the importance, growth and the reliance on the client/server model.
A client/server program consists of a client program module, referred to hereinafter as a client, assuming the role of a client. The client communicates with a server program module, referred to hereinafter as a server, assuming the role of a server. A client, as in real life, requests certain services of the server. A server, again as in real life such as a butler, performs the services requested by the client. In a client/server model, generally the server executes on one computer while the client executes on a remote computer which is connected to the server by a network. While this is not necessary, executing the client and the server on the same computer limits the advantages gained by doing otherwise. In order for most advantages of a client/server model to be gained, the time required for a server to meet the client request must be short. A client request which monopolizes the server and its resources moves from a client/server model to a master/slave model.
The client/server model has distinct advantages. First, a single server may service multiple clients almost simultaneously. Second, the server may act as a central repository for data files, database records, web pages, email data, and the like. Additionally, the server may execute on a computer which has many more computing resources such as disk space, memory, and computing speed than the computer on which the client executes. Centralizing the computing resources allows the server to execute complex or time consuming calculations on a client's behalf. A single client may not need the extra computing resources at any given time but may need the resources at a later point during a given time interval. Thus, centralizing the resources and allowing multiple clients access to them by way of a server maximizes the use of these resources.
An example of a server which provides primarily database records to clients is a database management system. An example of a database management system is the Information Management System (IMSTM) available from IBM Corp., Armonk, N.Y. The IMS system is used to serve records from a vast number of databases in operation today. The IMS system[s] allows access by clients to one or more databases in order for users to retrieve and modify the data maintained on the database. The majority of client access involves transactional operations.
A client/server model offers advantages in the design and programming of clients as well. In the design of the client and the server the software engineer may decide how much functionality to place in the client versus the server. Generally, functionality which maximizes computing resources is placed in the server. This functionality is often database records and their management or complex computing algorithms. This leaves primarily output and server request functionality for the client. Output functionality includes displays, reports or other human intelligible computer outputs. Clients with little more than output functionality are called thin clients. Thin clients require less computing resources on the remote computer. This allows the thin client to execute on a smaller, more compact computing device such as a Palm Pilot® or internet enabled mobile phone. A thin client also allows the client to be generalized such that the client may execute as a plug-in within a client driver program, such as Netscape® or Microsoft Internet Explorer®. Using thin clients also allows the program designer to protect proprietary algorithms on the server while still providing the service to the clients.
As mentioned above, the client/server model is most effective with transactional operations of short duration. In transactional operations, the client requests a service such as the data in a database representing a person's bank account balance. The transaction is complete when the server responds to the client with a response message containing the balance amount.
One premise gencrally relied on when using network protocols is that for each client request made of the server there will be a corresponding response sent to die client. Even if the response to the client is that the server oxperienced an error or could not service the request, the client expects at least some response message. Similarly the server anticipates that the client expects aresponse and makes arrangements to provide one. A protocol for use with the present invention, Open Transaction Manager Access (‘OTMA’), also relies on this premise. Response messages are stored in a data structure until the server is capable of sending them. Suitable data structures include, queues, linked lists, and the like.
During normal operation, the premise of expected response messages functions without any problems. Clients make requests using request messages and the server responds using response messages. A completed transaction is a request and its corresponding response message. A request and its corresponding response message comprise as a set of paired messages. The server response message is the pair for the client request message.
Unfortunately, operations between computers on a network are not completely free from communication interruptions. Interruptions may take various forms. The client may make a request and be taken off the network, or off-line, by the user of the client computer before the server could deliver the response to complete the transaction. Alternatively, the client may request a server perform a service and send the result to a second client which is not currently on-line.
Conventional servers ignore interruption scenarios. The server continues to store response messages in the queue and continues servicing other clients. Messages which have become undeliverable because of an interruption are called unpaired messages. The module in the server responsible for delivering the server responses continues to send out responses to clients currently connected to the server. A client is connected when it has indicated a desire to communicate with the server and the server has accepted to perform services for the client.
When communication has been prematurely interrupted, unpaired messages may accumulate in the server's message response queue. Once the same client re-connects to the server, the client may send the same request as prior to the interruption or send a completely different request. However, messages sent from the server to the client are sent on a first in, first out (FIFO) basis. That is the first message to be stored in the queue will be sent before subsequent messages stored in the queue. Therefore, the server sends, in response to the client's most recent request, the unpaired response message created in response to the last request prior to the interruption.
Because server response messages are sent on a FIFO basis client1 may request a service and ask that the response be sent to client2. At about the same time, client2 has made a completely different request. The request from client1 is quickly processed and a response to be delivered to client2 is placed in the queue. Then, client2's response is ready. Conventional server message delivery modules do not distinguish between paired and unpaired messages. The message for client2 from client2 is an unpaired message which the conventional delivery module simply sends to client2. Because this response is not the pair for the request client1 made, an error condition in client2 may result.
Some clients may have logic to enable the client to recover from an interruption and identify the unpaired response message sent by the server and work through the problem accordingly. However, most clients do not have such logic. These clients are expecting a response to their most recent request and instead are receiving an unpaired message. This mis-match, or disconnect in communication may lead to the client experiencing an error state or outputting erroneous data.
Solutions to the response message mismatch generally involve developing clients which have logic to manage unpaired messages. This logic increases the size of the client executable meaning the clients will require more computing resources. The computing resources required lowers the probability that the advantages of thin clients, mentioned above, can be recognized. Also, placing this logic in the client may require separate logic to handle unpaired messages from each server a client may interact with.
Thus, it would be an advancement in the art to provide a method to manage unpaired messages such that unpaired messages may be utilized by the clients even after a communications mismatch. It would be a further advancement to provide a system and method to manage unpaired messages in a single central server location rather than in each remote client. It would be a further advancement to provide unpaired message management without increasing the size of the clients. It would be yet another advancement in the art to provide unpaired message management by using existing server functionality rather than consuming additional client computer resources. It would be yet another advancement in the art to provide a method for managing unpaired messages such that the method may be initiated by a client's request. It would be yet another advancement in the art to provide a method for managing unpaired messages to recognize the existence of unpaired messages and automatically manage these messages for later delivery to the client. It would be yet another advancement in the art to provide a method for managing unpaired messages such that the client may request one or more unpaired message be sent to the client. Such an invention is disclosed and claimed herein.